Absence of test basis

If no test basis is present, the tester should go in search of other sources of information that can serve as a basis for creating test cases. Bach, Whittaker and Kaner have devised an approach for this:

HICCUPP [Bach, 2003] 

Information for creating test cases may be obtained, for example, from norms and standards, memos, user manuals, interviews, advertisements or rival products. Bach has set this out in his HICCUPP approach:

• History - Is the present operation of the software consistent with the previous operation?
• Image. Is the operation of the software consistent with the image of the organisation?
• Comparable. Is the operation of the software consistent with that of other comparable products?
• Claims. Is the operation of the software consistent with how people say it should operate?
• User expectations. Is the operation of the software consistent with what we (the testers) think the user wants?
• Product. Is the operation of specific software components consistent with comparable software components within the product?
• Purpose. Is the operation of the software consistent with the apparent aim of the software?

18 Attacks, by Whittaker and Jorgenson [Whittaker, 2000] 

Some software defects are so trivial that good standard tests (attacks) can be defined for them. The 18 attacks of Whittaker and Jorgenson listed below can form an excellent basis for creating tests or be used to supplement existing tests:

• User interface (input)
  1. Generate input that will provoke all the error messages.
  2. Generate input that will require all the default values to be entered
  3. Try to enter all the permitted symbols and data types
  4. Enter too many symbols
  5. Find correlations between input fields and test combinations of their values
  6. Enter the same data repeatedly.
• User interface (output)
  7. Try every possible output for every input
  8. Try to cause incorrect output.
  9. Try to change characteristics/values of the output.
  10. Refresh the screen
• Stored data
  11. Enter data from every possible starting point.
  12. Try to save too many or too few characters in the database.
  13. Try to find alternative ways of changing internal data restrictions.
• Calculations
  14. Try out incorrect operand and operator combinations.
  15. Try to get a calculation module to call itself.
  16. Try to make the resulting values too high or too low.
  17. Try to find functions that make use of the same data.
• System interface (media)
  18a. Make all the storage space unavailable.
  18b. Make the system busy or unavailable.
  18c. Damage the system.
• System interface (files)
  18d. Allocate an incorrect file name.
  18e. Change the permissions (including reading and writing permissions) of a file.
  18f. Change the content of a file, or corrupt it.

Kaner’s 480 bugs [Kaner, 1999]

Kaner has created a list of common software defects. This list can be used to find the same or similar defects in the software under test. Alternatively, the list can be used in a more general sense for:

• Gathering test ideas - Investigate whether a defect on the list could arise in the software under test. If this is theoretically possible, consider how you might find it. Then create test cases (or not) depending on the damage the defect could cause in production.
• Test design review - Select a few test situations from the test design and find a possible defect from the list for each test situation. Then examine, for each possible defect, whether it could occur in the software under test and whether it would then be found by the test cases created.
• Wider perspective - Check the list for types of defects that are often overlooked (out-of-the-box thinking).
• Training - Show new testers what can go wrong and have them create test cases with which these defects can be found.